1. Field of the Invention
The present invention generally relates to software development and more particularly to the simulation of hardware targeted by software being developed.
2. Description of the Related Art
Firmware generally refers to specialized software that typically includes low level machine readable code (i.e., microcode) used to provide an interface to various hardware components while isolating higher level software (i.e., an operating system or application running thereon) from the details of that hardware access. Typically, firmware is developed and tested like other types of software: a firmware specification is created based on the needs of a particular application, firmware is developed based on the specification, and the firmware is tested.
One of the common objectives accomplished in firmware is to configure hardware components, for example, in preparation for an intended use when a system is first powered up. Therefore, it is difficult to test firmware code without running on the actual hardware. In an effort to speed time to market, it is common to develop firmware and hardware in parallel. Unfortunately, while firmware testing needs to be done as soon as possible, often the hardware the firmware targets is not available. To prevent the unavailability of hardware from postponing firmware testing, operation of the firmware may be simulated, as if it were running with the targeted hardware.
There are generally two basic commonly used approaches to simulate firmware as if it were running in hardware, both with advantages and disadvantages. The first approach and, arguably the simplest, is software simulation that typically employs compiler flags, debuggers, and other such devices, to control the execution flow of the firmware, in an effort to “exercise” as much of the code as possible. In other words, the firmware code may be manually modified to force a particular path of execution, as if an identified hardware condition existed, in order to test a corresponding portion of the code. An advantage to this approach is that it requires very little preparation for each execution. However, this testing is likely to be manual (as execution paths are manually forced), and in order to exercise the firmware as if it were being run on the actual hardware, several iterations may be required, which may be extremely time consuming.
The second approach is to use a complete hardware emulation. Hardware emulation generally involves specialized equipment designed to behave in a nearly identical manner to the actual hardware being emulated. For example, an emulator for a hardware component may be developed based on the same hardware descriptive language (e.g., VHDL) that was used to build the emulated hardware. However, the specialized equipment used for emulation is typically very expensive and, even with the specialized equipment, emulation of the hardware may be relatively slow. For example, a typical operation that may take 100 milliseconds (ms) in the actual hardware may take several minutes in the emulator.
Accordingly, there is a need for an improved method for testing firmware, as if it were running in the actual hardware it targets.